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Summary 

The Federal Aviation Administration is trying to make 
its air traffic management system more responsive to the 
needs of the aviation community by exploring the concept 
of “free flight” for aircraft Hying under instrument flight 
rules. In free flight, en route aircraft fly user (i.e., pilot or 
airline)-dcfined trajectories with only minimal air traffic 
control (ATC) adjustments to avoid restricted airspace 
and separation loss with other aircraft. Free flight is 
expected to allow airspace users more flexibility in deter- 
mining optimal aircraft routing. In all current frcc-flight 
concepts, the efficient handling of aircraft in transition 
from en route to terminal airspace requires ground-based 
planning and control. When aircraft transition from en 
route to terminal airspace, their trajectories often must 
merge subject to in-trail separation or time-based flow 
constraints necessary for meeting airport capacity 
limitations. The unconstrained nature of free flight 
complicates these ground-based tasks even more. Hence, 
providing controllers with effective decision support tools 
that not only support free flight, but also support the 
transition of frec-flight aircraft into the terminal airspace, 
is essential. 

A logical first step toward free flight could be made 
without significantly altering current ATC procedures or 
requiring new airborne equipment by designing a ground- 
based system to be highly responsive to user preference in 
en route airspace w hile providing for an orderly transition 
to terminal areas. To facilitate user preference in all en 
route environments, a system based on an extension of 
the Center/TRACON Automation System (CTAS) is 
proposed in this report. The new system consists of two 
integrated components. An airspace tool (AT) focuses on 
unconstrained en route aircraft (e.g., not transitioning to 
the terminal airspace), taking advantage of the relatively 
unconstrained nature of their flights and using long-range 
trajectory prediction to provide cost-effective conflict 
resolution advisories to sector controllers. A sector tool 
(ST) generates efficient advisories for all aircraft, with a 
focus on supporting controllers in analyzing and resolving 
complex, highly constrained traffic situations. When 
combined, the integrated AT/ST system supports user 
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preference in any air route traffic control center (ARTCC) 
sector. The system should also be useful in evaluating 
advanced free-flight concepts by serving as a test bed for 
future research. This document provides an overview of 
the design concept, explains its anticipated benefits, and 
recommends a development strategy that leads to a 
deployable system. 

Introduction 

The Federal Aviation Administration (FAA) is trying to 
make its air traffic management system more responsive 
to the needs of the aviation community by exploring the 
concept of “free flight” for aircraft flying under instru- 
ment flight rules. (See refs. 1 and 2.) In free flight, 
en route aircraft fly user (i.e., pilot or airline)-defined 
trajectories with only minimal air traffic control (ATC) 
adjustments to avoid restricted airspace and separation 
loss with other aircraft. Frec-flight rules begin after the 
initial departure restrictions and end at the initiation of 
arrival sequencing to the destination airport’s terminal 
airspace. Because en route aircraft in free flight are not 
required to follow ATC-preferred jet routes, free flight is 
expected to allow airspace users more flexibility in 
determining optimal aircraft routing. Although significant 
economic benefits arc anticipated, very little is known 
about the effects of free flight across the national 
airspace. 

Through the FAA’s National Route Program (NRP), 
airlines currently can file requests to fly non-ATC- 
preferred routes (with some limitations). However, the 
complex interaction of user-preferred routing and 
dynamic changes in traffic density across the national 
airspace have limited the benefits of the program. (See 
ref. 3.) The problems experienced w ith NRP show that, if 
free-flight benefits are ever to be realized, the air traffic 
management (ATM) system will have to evolve through 
an FAA strategy of increasing decision support tools 
available to controllers, airlines, and pilots while 
gradually decreasing route constraints. In addition, this 
evolution must be accomplished safely and with no 
disruption in operations. 

In current frcc-flight concepts, the efficient handling of 
aircraft in transition from en route to terminal airspace 



will continue to require ground-based planning and 
control. When aircraft transition from en route to terminal 
airspace, their trajectories often must merge subject to in- 
trail separation or time-based flow constraints necessary 
for meeting airport capacity limitations. The uncon- 
strained nature of free flight complicates these ground- 
based tasks even more. Hence, providing controllers with 
effective decision support tools that not only support free 
flight, but also support the transition of frcc-flighl aircraft 
into the terminal airspace, is essential. 

A logical first step would be to achieve as many free- 
flight benefits as possible without significantly altering 
current ATC procedures or requiring expensive airborne 
equipment modifications. These benefits could be 
achieved by a ground-based system that is highly 
responsive to user preference in en route airspace while 
also providing for an orderly transition to terminal areas. 
User preference is the general term for any aircraft 
operation that is explicitly requested or assumed to be 
desired by the airline or pilot. Preferred aircraft operations 
can vary from non-ATC-prcfcrred routings to the use of 
airborne vertical navigation (VNAV) automation during 
descents into terminal airspace. In a system that requires 
positive ATC control, user preferences are facilitated (or 
enabled) through verbal or procedural ATC clearances. 
Developing decision support tools for controllers that 
identify user preferences and their effects on the current 
traffic situation would enable controllers to quickly assess 
the effort of incorporating user preferences into the 
current traffic plan. Furthermore, by designing auto- 
mation to determine the minimum change to the user 
preference required for incorporation into the traffic plan, 
a large step toward free-flight benefits would be achieved. 

To facilitate user preference in all en route environments, 
a system concept based on an extension of the Center/ 
TRACON Automation System (CTAS) has been devel- 
oped. (See ref. 4.) It consists of two integrated compo- 
nents. An airspace tool (AT) focuses on unconstrained 
en route aircraft (e.g., not transitioning to the terminal 
airspace), taking advantage of the unconstrained nature 
of their trajectories and using long-range trajectory 
prediction to maximize user efficiency by providing 
cost-effective conflict resolution advisories to sector 
controllers. A sector tool (ST) generates efficient 
advisories for all aircraft, with a focus on supporting 
controllers in analyzing and resolving complex, highly 
constrained traffic situations. When combined, the inte- 
grated AT/ST system supports user preference in any air 
route traffic control center (ARTCC or Center) sector. 

This system should also be useful in evaluating more 
advanced free-flight concepts by providing a test bed for 
future research. 


This document presents an overview of the design 
concept, explains its anticipated benefits, and recom- 
mends a development strategy that leads to a deployable 
system. The AT and ST are described in detail, and a 
new ATM position, the ‘‘airspace coordinator,'’ is defined. 
Examples of conflict resolution for typical conflict 
scenarios arc also given. 

Functional Design 

The integrated tools concept must accommodate the wide 
range of traffic environments found in the national 
airspace. At one extreme, generally associated with free 
flight, is an airspace consisting only of aircraft not 
constrained by traffic management or other localized, 
highly dynamic constraints. This environment, usually 
found in en route sectors well away from terminal 
airspace, is referred to in the following discussion as an 
“unconstrained" environment. If traffic density is low, 
very little ground-based ATC coordination or intervention 
is required. At the other extreme, in the en route area 
approaching an airport's terminal airspace, heavy traffic 
management is often required. Arriving aircraft must 
merge for sequencing while simultaneously adhering to 
crossing restrictions and avoiding conflicts with other 
aircraft. Referred to herein as “transitional," this traffic 
environment is characterized by a mix of unconstrained 
aircraft with many highly constrained aircraft transi- 
tioning to terminal airspace. Any traffic situation between 
these two extremes is possible in a single sector. The 
environment in a sector also changes, depending on the 
time of day. Adjacent sectors in a Center can have the 
same environment, or several sectors may represent a 
transition from one extreme to the other. Furthermore, a 
normally unconstrained en route sector can actually 
behave more like a transitional sector if an adjoining 
Center places traffic management (e.g., miles in trail or 
metering) restrictions on entering aircraft. The integrated 
concept facilitates the inclusion of user preferences in all 
these environments. 

An overview of the integrated concept is shown in 
figure I. The system is supplied with real-time radar 
track and flight-plan information from the Center Host 
computer or an advanced aircraft tracking system. The 
AT is independent of airspace seclorization, supporting 
a new “airspace coordinator" position whose objectives 
are maximizing user efficiency while reducing sector 
controller workload. The ST is sector controller centered, 
and facilitates traffic planning and intersector coordina- 
tion within and between Centers. To minimize changes to 
current ATC procedures, all clearances issued to aircraft 
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Figure 1. Airspace tool/sector tool functional concept. 





arc still issued by the sector controllers. Clearances based 
on advisories from the two tools or the airspace coordi- 
nator, however, reflect a much higher degree of user 
preferences integrated into current sector traffic planning. 

Airspace Tool 

The AT is designed to facilitate user preferences for en 
route flights that are not inhibited by localized, highly 
dynamic traffic constraints, generally for aircraft found 
outside high-density traffic areas and/or not transitioning 
to terminal airspace. The goal of the AT is to detect and 
resolve conflicts with a time horizon (approximately 20 to 
25 minutes) that is longer than the “decision-making time 
horizon” used by sector controllers, defined as the time 
normally required to realize a desired traffic plan by 
issuing clearances to resolve conflicts and achieve traffic 
management constraints (if any). Since the AT looks 
beyond the controller’s time horizon, the potential exists 
to resolve predicted conflicts more efficiently than 
waiting until the controller would normally detect them. 
AT resolutions are initially restricted to aircraft that are 
not affected by traffic management constraints since 
accurately predicting trajectories without detailed 
knowledge of the sector controller’s traffic plan is 
difficult. The addition of these constrained aircraft to the 
AT would require that the increased benefits outweigh the 
negative impact of incorrectly predicting the traffic plan. 
Constrained aircraft arc handled by the ST as discussed in 
the next section. 

Cost-effective conflict resolution advisories reflecting 
minimum deviations from user-preferred routes are 
provided by the AT in the form of horizontal path, 
altitude, and/or speed changes. A packet consisting of 
the advisory and information from which 'the modified 
resolution trajectory can be reconstructed arc sent to the 
ST for display and acceptance or rejection by the sector 
controller. If accepted, the advisory clearance is added to 
the known trajectory constraints for the affected aircraft 
(available to both the AT and ST for future trajectory 
predictions). If the advisory is rejected, the AT is notified 
so an alternative cost-effective resolution can be 
attempted. 

The AT cost-effective resolutions are based on the 
concept that there is both an optimal clearance to resolve 
a predicted future conflict and an optimum time to issue 
that clearance (ref. 5). A resolution advisory is made up 
of a suggested clearance and a time for its initiation; for a 
cost-effective resolution, the time is chosen to achieve a 
trade-off between maneuver efficiency and conflict 
certainty. The earlier a maneuver is initiated, the more 
efficient and easily executed it will be. For example, a 
small speed change well in advance of a conflict is more 


efficient than an altitude change close to the point of 
conflict. However, resolution maneuvers made too far in 
advance may often be unnecessary if conflict probabilities 
are low. The later a maneuver is initiated, the less effi- 
cient it will be, but the more certain it is that the conflict 
would have occurred. The optimal time to initiate a 
maneuver is determined by minimizing the cost of 
maneuvering as a function of lime. That function depends 
on the con 11 id probability (based on the trajectory pre- 
diction accuracy of both aircraft) and other parameters, 
such as the cost of a less-efficient flightpath and the level 
of controller workload required to resolve the conflict. 

The AT supports a new controller position, called the 
“airspace coordinator” (AC), located in the ARTCC. 

This person monitors an area of airspace larger than a 
single sector, interacting with the AT to enhance its 
functionality. In an initial implementation of the concept, 
the AT will display a conflict to the AC, who may resolve 
the conflict either manually or in conjunction with 
AT automatic resolution support. The AC w ill then 
communicate the advisory directly to the appropriate 
sector controller for issuance or rejection. If several AC 
positions are desired within a Center, coordination among 
these positions will be necessary; this scenario will be 
included in a future implementation. By supporting a 
controller dedicated to identifying and resolving predicted 
conflicts beyond the decision-making time horizon of 
sector controllers, deviations from user-desired trajec- 
tories are expected to be minimized without greatly 
increasing the workload of sector controllers. Also, 
because the AC analyzes and resolves multisector 
conflicts while observing traffic in all affected sectors, 
efficient resolutions can be obtained while reducing the 
required coordination between sector controllers. The 
AC should be able to direct AT resolutions to controllers 
with less workload without disturbing controllers in high- 
workload situations. It is anticipated that many of the 
initial manual AC functions will be automated as 
understanding of desired solutions to typical problems 
increases. 

Since the AT is designed to support the evolution of 
advanced concepts toward free flight, the AC position is 
expected to play an increasingly important role in future 
implementations of the concept. For example, the AC 
may eventually apply special real-time knowledge of user 
preferences (possibly after negotiation with the aircraft) to 
coordinate en route flights within Center airspace. This 
real-time knowledge will most likely be supplied by 
datalink or some alternative form of communication with 
the user (e.g., communication with the Airline Operations 
Center) that does not involve the sector controller. 

Because of the AC’s “big picture” perspective of airspace 
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operations, the AC’s responsibilities will eventually 
include more of a traffic management role. Specifically, 
in future enhancements the AT may measure and predict 
en route complexity (within a sector and overall) to 
ensure that sector controller workload is maintained 
within acceptable bounds and if not, develop and imple- 
ment plans to constrain aircraft routing so that tralfic 
complexity is reduced. The AT, with the AC, represents 
an extension of current ATC procedures and, when 
implemented, will serve as a platform for evaluation of 
advanced free- flight concepts. 

Figure 2 illustrates a possible AT interface to display all 
en route aircraft within a desired airspace region (e.g., 
greater than a single sector, possibly an entire area or 
Center) to the airspace coordinator, who has keyboard 
and trackball input devices for interacting with the tool. 
The interface, referred to as a dynamic conflict display, 
shows predicted conflicts and situational awareness 
information as well as pending AT resolution advisories. 
The display consists of a plan view representation of 
the airspace, showing the position of each aircraft, 
including requested data blocks. It is updated in real time 
(at intervals of 12 seconds or less) as new information, 
such as track updates, becomes available. Hach aircraft 
with a predicted conflict is lagged; further information 
about the conflict (e.g., projected time to the conflict and 
resolution advisory) can be requested. In addition, the 
display provides the AC with a prediction of regions that 
will have high conflict density, which may impose a 
difficult traffic management workload on the sector con- 
troller. Conflict density may be represented as the sum of 
probabilities for conflicts predicted to occur in any sector. 
Three schemes for display of sector conflict densities are 
presented in the figure: the lower right panel shows 
ranges of times to conflict for each sector, along with the 
worst case; the upper right and left panels show the 
degree of sector conflict loading (possibly color-coded) 
with time in two different formats. The AC is expected to 
use the density information to prioritize the conflicts. The 
figure should not be considered a final display interface; 
significant effort must be devoted to make the interface as 
effective and easy to use as possible. 

Sector Tool 

While the AT is oriented predominantly toward 
accommodating the user, the ST must accommodate the 
user while also assisting the controllers. Its primary goal 
is to support sector controllers in safely and effectively 
managing complex traf fic situations, such as those that 
occur in the transitional environment to terminal airspace, 
while facilitating as many user preferences as possible. Its 
design is based on the research performed for the descent 


advisor (DA) tool of CTAS (refs. 6 and 7). The ST serves 
as a situational display and intelligent-advisory aid, 
supporting the controller in devising and executing a plan 
for managing traffic in all environments, even those that 
are highly constrained by traffic management constraints 
(e.g., metering or miles in trail). As future traffic density 
increases and user preferences become more prevalent, 
the ST will be needed to handle higher traffic loads while 
enabling user-preferred trajectories to be extended further 
into the extended terminal area. 

The ST assists controllers by generating accurate, 
fuel-efficient clearance advisories for the merging, 
sequencing, and separation of high-density traffic w hile 
providing automation assistance for the prediction and 
resolution of conflicts between aircraft in all phases ol 
flight. It assists sector controllers by: 

• determining efficient descent trajectories for each 
aircraft, from cruise altitudes to the boundary ot the 
terminal airspace; 

• detecting potential conflicts and providing interactive 
aids for planning resolutions; and 

• providing real-time information to aid controllers in 
their overall traffic planning. 

One of the major ST functions is to provide descent 
clearance advisories, which are based on four- 
dimensional fuel-efficient trajectory predictions for 
descents from cruise altitudes to terminal area feeder 
fixes. Traffic management constraints are met while 
deviations from user-preferred descent profiles are 
minimized. Through the use of rapid update cycle 
weather information (ref. 8) and aircraft models, the 
ST predicts trajectories that arc of the same order of 
magnitude in accuracy as current airborne systems. The 
trajectory solutions are translated into ATC clearance 
advisories that include vector headings, cruise speed, 
aircraft top-of-descent (TOD) point, and descent speed 
profile (composed of a descent Mach number and/or an 
indicated airspeed). All ST advisories are continually 
updated to reflect changes in aircraft states and 
atmospheric predictions. 

The ST uses automatic conflict detection to alert the 
controller to potential separation conflicts over the 
controller’s entire decision-making time horizon. By 
using accurate aircraft trajectory predictions that reflect 
controller intent, the ST is expected to extend the current 
controller’s decision-making time horizon, thereby 
enabling more efficient planning. The display of potential 
conflicts is timed to help the controller manage the 
airspace. The time of display may also be based on a 
conflict probability threshold (which may be set by the 
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Figure 2. Dynamic conflict display (initial representation). 




controller). In addition to providing more advance time 
for traffic planning, automatic detection should enable the 
controller to resolve conflicts more efficiently. The 
increased confidence provided by automatic conflict 
detection may also be useful in reducing the number of 
conservative clearances that controllers currently issue to 
ensure separation when they arc unsure of whether a 
conflict will occur. 

Automatic conflict detection at the ST level will initially 
be implemented to display only conflicts between: 

• any pair of aircraft “owned" by that sector controller 
(independent of whether the conflict resides within 
the controller’s sector); 

• any “unowned" aircraft w ithin a controller-defined 
distance (or time) from the sector boundary and any 
other such unowned aircraft or any owned aircraft; or 

• any owned aircraft w ithin a controller-defined 
distance (or time) from its next sector and any 
aircraft within that next sector or any aircraft within a 
specified distance (or time) from and due to arrive in 
that next sector. 

To include probing the effects of other aircraft, the 
controller can manually identify the desired aircraft to be 
probed. Once an unowned aircraft has been identified, it 
is probed until the ST determines that it can no longer 
impact aircraft owned by the controller. Display of 
potential conflicts beyond sector boundaries to all sector 
controllers involved will facilitate the solution of 
multisector conflicts. 

The ST can aid a sector controller to quickly create and 
evaluate a provisional (“what-if’) plan through the use 
of provisional clearance feedback, which allows the 
controller to determine the effect of issuing a clearance 
without affecting other controllers or other parts of the 
automation system. In addition to provisional clearance 
feedback, controllers are expected to use the ST to 
provide information for maneuver feedback. For example, 
a controller may absorb required delay by turning an 
aircraft away from its intended metering fix, while 
observing a countdown in remaining delay to be 
absorbed. After the required amount of delay has been 
absorbed, the controller would turn the aircraft back on a 
path to the metering fix. 

The ST also helps the controller to monitor aircraft 
spacing by displaying separation information at points 
along predicted trajectories. In-trail spacing can be shown 
at a defined location (e.g., at a Center or terminal airspace 
boundary) for selected streams of aircraft (e.g., aircraft 
exiting into a specified, adjacent Center or assigned to a 
defined meter fix). Alternatively, minimum separation 


locations can be shown for two or more aircraft to iden- 
tify dynamic “choke points" for aircraft not on standard 
routes. The display includes options for showing all 
minimum separations, or just separations that are less 
than a specified value. The spacing function is expected 
to support the merging of traffic without requiring the 
traffic to conform to specific routes, altitudes, or speeds, a 
procedure often done to simplify predicting aircraft inter- 
actions. Spacing, provisional clearance feedback, and 
conflict detection are expected to greatly enhance the 
provisional planning capability of the sector controller. 

To a sector controller, AT resolutions represent either 
solutions to problems beyond their normal planning 
horizon or very efficient solutions for conflicts between 
nontransitioning, unconstrained aircraft. When AT 
resolution advisories are received, the ST automatically 
checks the affected sector controllers to see if they are 
configured to accept AT resolutions. Sector controllers 
can configure the ST to automatically reject AT 
resolutions to their sector if they deem their traffic load 
too heavy to analyze resolutions beyond their current 
decision-making time horizons. If any controller is not 
accepting AT resolutions, a rejection is automatically 
sent to the AT without any notification to the sector 
controllers. If all affected sector controllers are accepting 
AT resolutions, then the ST checks the advisories for 
possible conflicts w ith all cn route aircraft, using its 
controller-intent (i.e., provisional planning) information. 

It should be recalled that the AT is primarily concerned 
with unconstrained aircraft and that it has a limited 
knowledge of the often rapidly changing sector controller 
environment, so AT resolutions are not guaranteed, at this 
stage, to be conflict free. If a conflict is detected, the ST 
checks to sec if the affected sector controllers are 
configured to accept AT resolutions that have potential 
conflicts. Again, sector controllers can configure the ST 
to automatically reject AT resolutions that are not conflict 
free if they deem their traffic load to be too heavy to 
analyze this information. If all affected controllers are 
configured to accept the AT resolution, the ST displays 
the AT conflict information, any conflict information 
generated at the ST level, and the suggested resolution 
to the appropriate sector controller(s). If the resolution 
can be worked into the sector controller’s plan, the 
controller accepts the AT advisory and issues the 
clearance(s) to the aircraft; otherwise, the AT is notified 
of the resolution being rejected. 

Future objectives for the ST will continue to focus on 
sector controller traffic planning. The addition of 
automatic or semi-automatic conflict resolutions will 
further reduce controller workload and facilitate intcr- 
sector coordination. Automatic resolution techniques 
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designed for the CTAS DA (ref. 9) are directly applicable 
to ST traffic problems. Integration with improved 
scheduling automation will allow the ST to automatically 
take lime-based traffic management constraints into 
account. Finally, exchange of information between the 
ST and airborne flight management systems (FMSs) has 
the potential to greatly reduce frequency traffic and 
clearance adherence errors (ref. 7). 

As in the current plan-view display (PVD), the ST 
displays to each sector controller all the aircraft tracks 
visible within a selected area. Superimposed on this 
display is any appropriate ST and/or AT advisory 
information being considered by that controller. The 
controller always has the option of removing all AT 
and/or ST advisories from the display. The ST display 
interface is based on the interface used in the DA; it 
provides keyboard-trackball input, and is updated in 
real time (typically every 12 seconds or less) as new 
information (e.g., track updates and controller inputs) 
becomes available. 

All display features will ultimately be integrated into an 
advanced display (such as the display system replace- 
ment, or DSR), but some features may appear in early 
development phases on an auxiliary display interface, 
as shown in figure 3, where an example of controller 
interaction with the ST is shown. In the figure, flight 
UAL001 must be delayed to meet a desired crossing time 
(13:01) at the TOMSN metering fix while avoiding a 
conflict with overflight UAL002. Through interacting 
with the ST’s provisional planning tools, the controller 
has determined that a horizontal path stretch with 
turnback directly to TOMSN is a workable solution. In 
this case, the controller issues the path stretch clearances 
to UAL001 at the turnout and turnback points, followed 
by a descent clearance approximately 30 n. mi. prior to 
the TOD point. The AT-detected conflict between 
UAL 1 00 and UAL200 is also shown with supporting 
information. The AT resolution advisory of a 20-knot 
indicated air speed (KIAS) reduction is shown on the 
fourth line of the data tag for UAL200. (Note that the 
fourth line is used for illustrative purposes only.) The AT 
and ST advisories will be designed so the controller can 
easily distinguish between them, possibly through color- 
coding or blinking. The figure should not be considered a 
final display interface; significant effort will be devoted 
to make the interface as effective and easy to use as 
possible. 

Integrated AT/ST Tools 

The needs of any en route traffic environment can be met 
through integration of the AT and ST. In a completely 


unconstrained cn route environment, a high percentage of 
AT resolution advisories arc expected to be accepted by 
the sector controllers and issued as clearances to the 
aircraft, thereby facilitating user preferences. Traffic 
management planning in this environment is generally 
low, so the controller is able to treat the AT resolutions 
like current user requests. In a transitional environment 
with numerous aircraft arriving to the terminal airspace, 
the sector controller is concerned primarily with devising 
and executing a plan for managing traffic flow. Therefore, 
the cost-effective resolutions provided by the AT will 
likely conflict with the controller’s traffic plan and will 
often be replaced by the provisional planning solutions of 
the ST. For a highly congested, unconstrained, cn route 
environment with many randomly scattered conflicts, the 
AT and ST each contributes to the traffic management 
solution: the AT provides a dynamic display of high- 
conflict areas to aid in airspace coordination, and the ST 
aids the controller in executing a traffic management 
plan. Since most traffic environments are a mixture of 
constrained and unconstrained aircraft, it is expected that, 
in general, both the AT and the ST will contribute to 
facilitating user preferences in all en route sectors. 

Table I summarizes the conflict detection and resolution 
capability differences between the two tools for an initial 
implementation. The AT considers unconstrained, 
nontransitioning, en route aircraft only since it is not 
integrated with the traffic planning provisional solutions 
necessary to handle flights transitioning to the terminal 
area. For transitioning aircraft, required traffic manage- 
ment constraints are achieved while facilitating as many 
user preferences as possible; the ST handles this environ- 
ment. The AT resolutions arc designed to handle conflicts 
beyond the controller decision-making time horizon, 
assuming no changes in either the aircraft’s current path 
or its altitude. By definition, aircraft transitioning to/from 
the terminal area require large speed and altitude changes 
wbthin the controller’s decision-making time horizon. 
Departing aircraft can be handled by the AT outside of 
terminal airspace if the climb segment is not constrained 
by traffic management restrictions. (Note: Satellite 
departures are considered transitioning aircraft if they are 
transitioning to a nearby airport.) Because the AT is 
intended to provide coordination over all en route 
airspace, its conflict detection responsibilities include the 
entire Center. For each sector, the ST is responsible for 
conflict detection over each sector controller’s planning 
horizon, which typically includes the controller’s sector 
and neighboring sectors. 
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Table 1 . Initial AT/ST conflict probing characteristics 



Airspace tool 

Sector tool 

Aircraft probed 

Unconstrained en route traffic only 

All en route traffic 

Trajectory constraints 

None 

Traffic management 

Detection responsibility 

Entire Center airspace 

For each sector, all aircraft within sector 
and individual aircraft in neighboring 



sectors 

Conflict displayed to 

AC a for resolution 

SC(s) b 

Conflict resolution 

AC resolves conflicts with AT and sends to ST 
(AC can negotiate resolutions with sector 
controllers) 

SC manual resolution (aided by ST 
through provisional planning aids) 


SC issues clearances 


Resolution type 

Cost-effective trajectory with provisional 
planning aids 

ST provisional planning aids 


“AC = Airspace Coordinator 
b SC = Sector Controller 


In order for the cost-effective AT resolutions to have an 
impact in an environment in which the AT and ST are 
working together to facilitate user preferences for a 
mixture of both unconstrained and constrained aircralt, 
the resolutions must be available to the sector controller 
before the conflict is within the controller’s decision- 
making time horizon. Work based on current prediction 
accuracy suggests that these cost-effective resolutions 

would generate advisories approximately 10 to 

14 minutes in advance of the conflict (rel. 5), a time 
that is expected to be within the prediction horizon 
needed for the ST. However, reference 5 indicates that 
increasing trajectory prediction accuracy increases the 
advance time of the minimum-cost point. One prediction 
error source is the existing FAA radar tracking algorithm 
of the Center Host computer. Using an advanced radar 
tracking system (ref. 10) is expected to improve predic- 
tion accuracy, thereby enabling minimum-cost resolutions 
20 or more minutes in advance. The system is now in 
place for testing at the Denver ARTCC, and its accuracy 
is being verified through analysis ot flight-test data. 

Conflict Resolution Scenarios 

Since much of the concept relies on providing increased 
flexibility (e.g., routing) for users, considerable attention 
has been given to determining how the integrated tools 
will help resolve conflicts. In this section, the anticipated 


operation of the tools is described in some detail lor 
several conflict scenarios. The expected benefits ot the 
integrated tools in each traffic environment arc also 
discussed. Four typical separation conflict scenarios are 
identified in figure 4. Consider the numbered areas to be 
sectors within a Center. In the figure, the sectors are 
shown to be horizontally adjacent, but the scenarios also 
hold for vertically adjacent sectors. They even hold tor 
adjacent sectors in different Centers, although the 
coordination between facilities will be more complicated. 
For convenience in the discussions that follow, all the 
conflicts are shown to occur in sector 2. 

Figure 4(a) shows an example of an “intrasector” conflict, 
the situation where both aircraft and the predicted point 
of conflict (i.e., initial loss of minimum separation 
requirements) are within a single sector. This scenario 
should yield the most straightforward resolution since 
only one controller is involved. A somewhat more 
complicated scenario, an “external ’ conflict, is shown in 
figure 4(b): both aircraft are in one sector, and the point 
of conflict is in another. Figure 4(c) shows an “external 
intruder” scenario: one aircralt and the predicted conflict 
point are in one sector, and the other aircralt is in another 
sector. Figure 4(d) shows an “intersector” conflict, where 
the two aircraft are in different sectors and the predicted 
conflict point is in a third sector. The latter two scenarios 
generally require the greatest amount of coordination 
between controllers. 
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(a) "Intrasector” conflict. 


(b) "External" conflict. 



(c) "External Intruder” conflict. 


(d) "Intersector” conflict. 


Figure 4. Typical conflict scenarios in a multisector environment. 
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Three of these scenarios (b, c, d) may involve the 
coordination of two or more sector controllers. The ST 
facilitates efficient intersector coordination by identifying 
which controllers need to be made aware of conflicts and 
then displaying conflict information accordingly. In some 
cases where aircraft owned by different controllers are 
involved, the ST may notify both affected controllers or 
only the controller that would be expected to resolve the 
conflict. By displaying the conflict to the controller who 
can most efficiently resolve a conflict before displaying to 
other affected controllers, efficient resolutions can be 
facilitated. In other cases, the ST may notify a controller 
to contact another sector to negotiate a solution. It may 
also be possible to use the ST automation and display aids 
to facilitate efficient negotiation between sectors. In this 
case, controllers will have the capability to share their 
provisional planning information during negotiation, 
greatly simplifying the coordination process currently 
done by phone. 

The ST uses “controller awareness” boundaries to define 
the horizon for displaying conflict detection results within 
adjacent sectors. Each adjacent sector pair (c.g, sectors 1 
and 2) is represented by four awareness boundaries, two 
for traffic flowing in each direction. Figure 5 illustrates 
the two boundaries for traffic flowing from sector 1 
(upstream sector) to sector 2 (downstream sector): 

• Upstream controller's awareness boundary: 

a specified distance or time from the downstream 
sector within which the upstream controller becomes 
aware of conflicts between upstream aircraft within 
the horizon and aircraft in the downstream sector 

• Downstream controller's awareness boundary: 

a specified distance or time from the downstream 
sector within which the downstream controller 
becomes aware of conflicts between upstream aircraft 
within the horizon and other upstream aircraft within 
the horizon or aircraft in the downstream sector 

The distance or time that defines a boundary may be 
defined as a function of aircraft type (e.g., jet versus 
turboprop or unconstrained versus transitioning). Recall 
that ST-dctected conflicts between aircraft in the same 
sector are displayed to the controller who owns the 
aircraft as long as the conflict is within the controller’s 
decision-making time horizon, independent of the sector 
in which the conflict resides, so no awareness boundary is 
required for this case. Downstream controller awareness 
boundaries are used for display of both ST and AT 
conflict information. The downstream controller may 
configure display criteria for AT information separately 
from ST information. The upstream controller boundary 


is necessary only for ST conflict information since AT 
resolutions are assumed to be for conflicts beyond the 
upstream controller’s decision-making time horizon. 

When an aircraft crosses a controller’s awareness 
boundary, the ST displays information to that controller 
about conflicts between the aircraft and any other aircraft 
in the downstream sector or any aircraft that has also 
crossed that awareness boundary. In figure 5, aircraft A 
is predicted to have a conflict in the downstream sector. 
When aircraft A crosses the awareness boundary for the 
upstream controller (SCI), the ST displays the conflict 
information to SCI ; when the aircraft crosses the aware- 
ness boundary for the downstream controller (SC2), the 
conflict information is displayed to SC2. The positions of 
the boundaries are configurable (and interchangeable); 
they are expected to be set by mutual agreement between 
coordinating controllers. By interchanging the order that 
an aircraft crosses the boundaries, the adjacent sector 
controllers can define, on a sector-by-sector basis, which 
controller (upstream or downstream) will be aware of the 
conflict first (i.e., who will have the first attempt at 
resolving the conflict). It is unclear at this time whether 
two or just one combined boundary will be necessary in 
all or some environments. During development, human 
factors research will be performed to determine the 
number and best sequence of awareness boundaries to 
most effectively resolve multiple controller resolutions. 
The use of awareness boundaries is more fully described 
in the scenarios that follow; one combined awareness 
boundary is assumed in all references to intersector 
coordination unless otherwise noted. 

In the following analysis, operation of the integrated 
tools is described for each conflict scenario in two traffic 
environments: a completely unconstrained en route 
environment and a transitional environment with many 
aircraft transitioning to a terminal airspace. An overview 
of the expected integrated system behavior is presented 
in table 2. As previously discussed, in a completely 
unconstrained en route environment, the AT is expected 
to detect most conflicts and provide cost-effective 
resolutions. In a transition to terminal airspace environ- 
ment, the ST is expected to be the primary tool, and AT 
resolutions will be used only if they do not adversely 
impact the controller’s traffic plan. Although these factors 
might affect the display options a controller would select 
or how a controller might respond to an AT advisory, the 
logic for each scenario presented in figures 6(a) through 
6(d) and discussed in the following sections should be 
considered independent of the traffic environment. 
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Upstream Controller's Awareness Boundary 
Downstream conflict will be displayed to 
upstream controller 



Downstream Controller's Awareness Boundary 
Downstream conflict will be displayed to 
downstream controller 

Figure 5. Intersector coordination boundaries. 
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Tabic 2. Expected conflict resolution behavior of the AT/ST system 


Conflict type 

Unconstrained environment 

AT resolutions predominant; ideally AT resolves 
before SC “sees” contlict 

Transitional environment 

ST resolutions predominant since many 
aircraft are transitioning (AT resolutions are 
likely to conflict with traffic plan) 

Intrasector 

SC accepts AT resolution when conflict identified 
earlier by AC; cost-effective solution desirable 

AT resolutions used only if they do not 
interfere or conflict with arrival plan 

External 

Aircraft owner resolves conflict 

Option: alert conflict owner to negotiate resolution 

Display of conflict to contlict owner facilitates 
early handoffs 

Aircraft owner “sees” conflict and resolves it, 
even if not probing other aircraft within 
conflict sector 

Display of conflict to conflict owner 
facilitates early handoffs 

External intruder 

Either SC (or both) resolves conflict, selected by 
AC/AT based on situation 

If one SC rejects AT resolution, AC/AT can try 
other SC 

Conflict detected by ST when intruder is 
within probing range of conflict sector 

Either SC (or both) resolves conflict 

Intersector 

Either SC (or both) resolves conflict, selected by 
AC/ AT based on situation 

If one SC rejects AT resolution, AC/AT can try 
other SC 

Option: alert conflict owner to negotiate resolution 

Display of conflict to conflict owner facilitates 
early handoffs 

Conflict displayed by ST when both aircraft 
are within awareness boundaries of conflict 
sector 

Either SC (or both) resolves conflict 

Display of conflict to conflict owner 
facilitates early handoffs 
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Intrasector Conflict: 

Aircraft A owned by SC2 
Aircraft B owned by SC2 
Conflict in sector 2 

SC Sector Controller 
ST Sector Tool 
AC Airspace Coordinator 
AT Airspace Tool 


When AT detects a conflict: 

AT displays conflict to AC; 

AC/AT resolves one/both trajectories; 

AT sends conflict/resolution to ST. 

If SC2 has configured ST to accept: 

ST probes resolution for conflicts, 
displays probe results and the resolution 
to SC2. 

If SC2 accepts resolution: 

SC2 issues clearance(s) 
or: 

Persistent conflict will be handled by 
ST. 

SC2/ST notifies AT/AC of decision. 


When ST detects a conflict: 

ST displays conflict to SC2; 

SC2/ST resolves one/both trajectories; 
SC2 issues clearance(s). 


(a) “Intrasector” scenario. 
Figure 6. Conflict resolution. 


15 




External Conflict: 
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Aircraft A owned by SC4 
Aircraft B owned by SC4 
Conflict in sector 2 

SC Sector Controller 
ST Sector Tool 
AC Airspace Coordinator 
AT Airspace Tool 


When AT detects a conflict: 

AT displays conflict to AC; 

AC/AT resolves one/both trajectories; 

AT sends conflict/resolution to ST. 

If SC4 has configured ST to accept: 

ST probes resolution for conflicts, 
displays probe results and the resolution to 
SC4; 

ST may display conflict and message to 
SC2. 

If SC4 accepts resolution: 

SC4 issues clearance(s) 
or: 

Persistent conflict will be handled by ST. 
SC4/ST notifies AT/AC of decision. 


When ST detects a conflict: 

ST displays conflict to SC4; 

ST may display conflict and message to SC2. 
If SC2 obtains handoffs of both aircraft: 
SC2/ST resolves one/both trajectories; 

SC2 issues clearance(s) 
or: 

SC4/ST resolves one/both trajectories; 

SC4 issues clearance(s). 


(b) “External” scenario. 
Figure 6. Continued. 
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Figure 6. 
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Intersector Conflict: 

Aircraft A owned by SC 1 
Aircraft B owned by SC4 
Conflict in sector 2 

SC Sector Controller 
ST Sector Tool 
AC Airspace Coordinator 
AT Airspace Tool 


When AT detects a conflict: 

AT displays conflict to AC; 

AC/AT resolves one trajectory (aircraft A); 
AT sends conflict/resolution to ST; 

If SCI has configured ST to accept: 

ST probes resolution for conflicts, 
displays probe results and the resolution 
to SCI; 

If SC4 has configured ST to accept: 

ST displays conflict and message to 
SC 4 ; 

If SC2 has configured ST to see conflicts: 
ST displays conflict and message to 
SC2. 

If SCI accepts resolution: 

SCI issues clearance to aircraft A. 

SCI /ST notifies AT/AC of decision. 

If resolution for aircraft A is rejected: 
AC/AT resolves trajectory for aircraft B 
or persistent conflict is handled by ST. 


When ST detects a conflict: 

ST displays conflict to SCI and SC4 
when within awareness boundaries; 
may display conflict and message to SC2. 
If SC2 obtains handoffs of both aircraft: 
SC2/ST resolves one/both trajectories; 
SC2 issues clearance(s). 
or: 

SCI and SC4 negotiate a resolution; 

SCI and/or SC4 issue clearance(s). 


(d) “Intersector” scenario. 
Figure 6. Concluded. 
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Intrasector Conflict 

If the AT detects a conflict between two aircraft 
(fig. 6(a)), a cost-effective resolution for one or both 
trajectories is determined and sent to the ST. If the 
sector 2 controller (SC2) is configured to be notified of 
AT advisories, the ST checks the trajectories associated 
with this resolution against all controller-intent trajectory 
predictions (including all provisional plans). If the AT 
resolution is in conflict with any of these trajectories, and 
SC2 is configured to not allow conflicting AT resolutions, 
the ST notifies the AT that the advisory cannot be used. If 
the AT resolution is not in conflict or SC2 is configured 
to allow conflicting AT solutions to be displayed, the ST 
displays both ST conflict probe results (if any) and the 
AT conflict and resolution information to the controller, 
who then has the option to issue a clearance or reject the 
advisory. If the ST delects conflicts with the AT resolu- 
tion, SC2 will have to develop additional clearances 
through provisional planning to resolve these conflicts. 
Finally, SC2 notifies the AT of acceptance or rejection 
through the ST interface. If the advisory is rejected, the 
AT updates a resolution constraints list and if feasible, 
AC/ AT generates a new resolution for the conflict. If 
accepted, the advisories are anticipated to reduce overall 
controller workload by solving conflicts well in advance 
of potential conflicts while providing cost-effective 
resolutions based on user preferences. 

When the ST detects a conflict within the decision- 
making time horizon of the controller, it is displayed to 
SC2. The controller then resolves the conflict using the 
provisional planning aids provided by the ST. When a 
satisfactory resolution has been obtained, SC2 issues a 
clearance to the aircraft. Of course, if one or both of the 
conflicting aircraft are transitioning, the AT will not have 
detected the conflict. If both are unconstrained, however, 
situations may occur where the ST displays a conflict 
when the AT does not. A possible scenario occurs if the 
AT resolution advisory has already been rejected or it 
will not be cost effective until the aircraft is within the 
controller’s decision-making time horizon. If the con- 
troller has previously rejected the AT advisory, then the 
ST resolution is utilized. If an AT resolution is still 
possible, it is at the discretion of the controller to decide 
if waiting for a cost-effective AT resolution is appropriate 
under the current situation. It is expected that a controller 
would wail for an AT resolution only if traffic conditions 
were relatively light. Human factors research will be 
necessary to determine the best display options if both 
AT and ST resolutions are available. 


External Conflict 

If both aircraft are unconstrained, en route aircraft 
(fig. 6(b)), the AT detects a conflict and provides a 
resolution to the ST, as in the intrasector scenario. If the 
resolution passes the SC4/ST display-configuration logic 
(see intrasector scenario case), the conflict information 
and resolution are displayed to SC4. If both aircraft are 
within the awareness boundary for SC2 (downstream 
controller’s awareness boundary), the ST displays the 
conflict to SC2 along with a message that a resolution is 
pending in sector 4. In this way, SC2 is made aware of 
upstream decision making that may be of interest; voice 
communication between the two controllers is not 
required. SC4 then has the option to either issue a 
clearance or reject the advisory. As in the previous 
scenario, the AT is notified of acceptance or rejection of 
the advisory, and if rejected, the AC/AT may attempt 
another solution. 

If the ST detects a conflict, it displays the conflict 
information to SC4, even though the conflict occurs 
outside sector 4. Recall that the conflict is displayed to 
SC4 even if one or both aircraft are outside SC4’s 
awareness boundary since the upstream controller’s 
awareness boundary is for displaying conflicts with 
aircraft in sector 2 (conflicts between aircraft owned by 
the same controller are always detected by the ST, 
independent of the sector in which the conflict exists). 

SC4 then uses the provisional planning capability of the 
ST to resolve the conflict and issue a clearance to the 
aircraft. The ST also displays the conflict to SC2 if both 
aircraft are within SC2’s awareness boundary (i.e., the 
downstream controller’s awareness boundary). The 
display of conflict information to the dow nstream sector 
allows for SC2 to request an early handoff if desired. If 
SC2 does not request and obtain handoffs for aircraft A 
and B, the resolution is performed by SC4 as described. 

In general, for conflict resolution involving more than one 
controller, there is a potential to lower workload through 
the SC/ST display logic discussed previously. For typical 
choke-point sectors (such as a low-altitude sector contain- 
ing a feeder fix), a benefit in providing an upstream 
controller with an opportunity to resolve the conflict is 
also possible, thereby redistributing the overall workload. 
In addition, if an upstream solution is not desired, SC2 
has the option to resolve the conflict by requesting early 
handoffs from SC4. These workload benefits are expected 
to apply to many traffic situations, so the controllers will 
have a strong incentive to take full advantage of the 
integrated tools. 
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External Intruder Conflict 

For the external intruder conflict case (fig. 6(c)), assume 
that the AT has chosen to modify the trajectory of aircraft 
A in order to resolve the conflict predicted to occur in 
sector 2. When the ST receives the conflict resolution 
packet that contains the advisory for aircraft A, it checks 
the display logic for SC2. If SC2 is configured to accept 
AT resolutions, the ST probes for conflicts. Finding none 
(or if SC2 is accepting AT resolutions with ST conflicts), 
the ST displays the conflict information and resolution to 
SC2. If SC4 has also been configured to accept display of 
AT advisories, the conflict information is displayed with 
a message that a resolution is pending in sector 2. This 
message is important to alert SC4 that any clearance 
issued to aircraft B at this time may cause the AT 
resolution to be invalidated and that sector 2 should be 
notified if verbal negotiation is desired. SC4 will also 
be aware that, if SC2 rejects the advisory, the AT may 
resolve the conflict by modifying the trajectory for 
aircraft B. Again, all situational awareness is accom- 
plished without need for voice communication between 
controllers. 

If the conflict has not already been resolved by the AT, 
the ST detects the conflict and displays the conflict 
information to SC2 and SC4 after aircraft B crosses the 
awareness boundary and when the conflict is within the 
decision-time horizon for each controller. The resolution 
may be performed by SC2 for aircraft A, by SC4 for 
aircraft B, or for both aircraft in a negotiated solution. In 
early implementations, the decision of who will resolve 
the conflict is made verbally (or procedurally) between 
the two affected controllers. ST provisional planning aids 
are expected to be used by the controllers for resolution. 
Display of conflict information to both controllers may 
also facilitate an early handolf of aircraft B to SC2 if 
desired. 

Early implementations of the integrated tools may require 
the AC to perform the role of selecting which aircraft 
receives the AT advisory. In this example, the AC may 
know that the traffic situation in sector 2 makes aircraft B 
more appropriate than aircraft A for receiving a resolution 
advisory. By placing the integrated tools in operation with 
functions such as this performed manually, data can be 
generated that will serve as a basis for a heuristics-based 
set of aircraft selection criteria, w hich could later be 
automated. In addition, the external intruder scenario 
would benefit greatly from automatic conflict resolution 
in the ST, which will also be developed for an advanced 
implementation. ST automatic resolution logic would 
parallel the logic of the AT; it would remove much of the 
need for negotiation between controllers for scenarios that 
require resolutions based upon controller intent. 


Intersector Conflict 

Again assume that aircraft A is chosen by the AT to 
resolve the conflict. When the ST receives the AT 
advisory for aircraft A (fig. 6(d)), it checks the display 
logic for SCI, and if SCI is configured to accept, the ST 
displays the resolution advisory to SCI. If the resolution 
is acceptable, SCI then issues the clearance. If SC4 is 
configured to display AT advisories, the conflict infor- 
mation is displayed with a message that a resolution that 
involves aircraft B is pending in sector 1 . Again, SC4 
knows that any clearance issued to aircraft B at this time 
may invalidate the AT advisory. In addition, SC2 may be 
informed about the conflict situation by display of the 
conflict and a message that a resolution involving aircraft 
A and B is pending in sector 1 . SC2 is informed of the 
conflict if both aircraft are within their respective aware- 
ness boundaries, and SC2 has all information needed to 
know the AT resolution plan. If the AT advisory inter- 
feres with SC2 traffic planning, SC2 can ask SCI to reject 
the AT advisory and/or negotiate with both controllers for 
early handoffs. 

Assume that the ST detects a conflict between aircraft A 
and B. SCI and SC4 have the conflict displayed w'hen 
both aircraft have crossed the awareness boundaries 
with respect to sector 2 and are within the controllers' 
decision-making time horizon. The two controllers then 
use the ST provisional planning aids and work together 
to negotiate a solution. SC2 also sees the conflict and 
aircraft information if SC2’s display is configured to 
show all potential conflicts within sector 2. Again, il SC2 
wishes to resolve the conflict, SC2 may ask for early 
handoffs of both aircraft. 

Because the intcrscclor scenario occurs when aircraft in 
separate sectors have a conflict predicted at a point 
outside either sector, it is the most complicated situation 
for sector controller coordination; therefore, it offers the 
greatest potential for increased efficiency and reduced 
workload. As in the external intruder scenario, large 
benefits are expected by using the AT to coordinate 
conflict resolutions that involve two or more controllers. 
The manual negotiations currently required for solving 
multisector conflicts can be reduced significantly, so 
controllers should have an incentive to use the tool. Early 
implementation of the integrated tools may require the 
AC to perform the coordination role for AT advisories. 

As in the previous scenario, ST automatic conflict 
resolution (to be implemented in an advanced develop- 
ment) is expected to further reduce the need for verbal 
controller coordination. 
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Development Strategy 

A phased development approach is proposed that focuses 
on obtaining benefits as early as possible, validating the 
concept under real-world conditions, and using opera- 
tional experience to expand tool capabilities. Table 3 
summarizes a three-phase development strategy. Phase 1 
concentrates on demonstration of the core capabilities 
of the individual AT and ST tools and develops the 
functionality necessary to perform concept validation. 
Phase 2 provides an initial integrated tools capability, 


with many of the tool functions performed manually. 
Both simulation experiments and field testing are an 
integral part of Phases l and 2 development. Phase 3 
provides the fully developed integrated system described 
in this document, including its use as a research platform 
for advanced concepts. Simulations and field evaluations 
will be used during this phase to automate many of the 
manual functions developed in earlier phases. With 
adequate staffing, the development could be completed 
in about four years. 


Table 3. Development strategy 


Phase Capability Function 


1 

Concept feasibility 
demonstration 


AT automatic conflict detection advisories 

AC manual notification of potential conflicts to 
area through voice communication 

SC/ST conflict detection and provisional 
planning through an auxiliary display 


AT 

Automatic conflict detection 
Dynamic conflict display 
ST 

Auxiliary display 

Descent advisory aids 

Manual and limited automatic conflict 
detection 


Spacing advisory aids 


Provisional planning aids 


2 

Initial operating 
capability 

AT automatic conflict detection advisories 

AT cost-effective resolution advisories displayed 
to AC 

AC/AT provisional planning 

AT advisories passed to ST (approved by AC) 

SC/ST automatic conflict detection, provisional 
planning, and spacing aids display to an auxiliary 
controller through a fully developed interface 

All Phase 1 functions 
AT 

Provisional planning aids 
Cost-effective resolutions 
ST 

Mature display interface 
Full automatic conflict detection 

3 

AT conflict detection and resolution advisories 

All Phase 2 functions 

Full operating 

AT advisories passed to ST (monitored by AC) 

AT 

capability 

SC/ST automatic conflict detection, provisional 

Cost-effective resolutions enhanced to 


planning, and spacing aids display at sector via 

include AC response to AT resolution 


an advanced display interface 

rejection 


Fully developed logic for ST probing of AT 

ST 


resolutions and display to sector controller 

AT resolutions probing logic 


Fully developed logic for AT response to 

Display configuration logic 


resolution rejection 

Deployable display interface (such as 



DSR) 
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Phase 1 

In the first phase, the AT and the ST will he developed 
and evaluated as independent decision support aids. All 
integration between the AT and the ST is performed 
manually. A strong emphasis will he placed on develop- 
ment and evaluation of the core capabilities of each tool, 
and on validation of the fundamental concepts. In 
addition to laboratory development and evaluation, the 
tools will undergo operational evaluation in a limited 
area of en route airspace, involving a few representative 
sectors (representing both traffic environment extremes) 
that are chosen based on development and evaluation 
goals. All display interfaces will be developed only to a 
level that permits concept evaluation and human-factors- 
related research. 

The AT will provide automated detection of potential 
conflicts and the probabilities associated with these 
predictions for en route aircraft in the Center airspace. 
The dynamic conflict display will be used to provide this 
information to the AC, who may then notify the appro- 
priate area supervisor of projected areas of high conges- 
tion through voice communication. The sector controllers 
will use the ST to probe for predicted spacing and 
conflicts between specified aircraft (manual or limited 
automatic conflict detection), resolve predicted conflicts 
through provisional planning, and support aircraft in 
making efficient descents. An advanced radar tracker 
will be used to make accurate conflict predictions up to 
20 minutes in advance. 

Research for Phase 1 will concentrate on validating 
concept feasibility. It will be designed to answer funda- 
mental questions regarding benefits to controllers and 
users. The research will also focus on defining needed 
operational procedures (e.g., intersector coordination) and 
the key elements of a mature display interface through 
controller evaluations. Some of the concept feasibility 
issues to be explored are: 

• the effectiveness of the dynamic contlict display in 
assisting the AC in managing the airspace; 

• the extent of the assistance the ST provides to the 
controller in devising and executing traffic plans, 
especially for managing transitioning aircraft; 

• the appropriate sector controller decision-making 
time horizon for aircraft trajectories with differing 
traffic management constraints; 

• whether the controller considers the benefits received 
from the ST to outweigh the additional workload 
required to interface with the tool; 

• the expected time horizon for AT cost-effective 
resolutions based on advanced radar tracker data, and 


the timeliness of these resolutions in accommodating 
user preferences and not infringing upon controller 
intentions; 

• the sensitivity of AT cost-effective resolutions to 
sector controller issuance timing and its effect on 
resolution effectiveness; and 

• the appropriate probability threshold for display of an 
ST-detected conflict to a controller. 

Phase 2 

In the second phase, most of the capabilities of the fully 
developed integrated tools will be achieved by allowing 
some of the tasks to be performed manually. The AT w ill 
provide cost-effective resolutions to the AC, who will 
then use experience-based judgment to determine whether 
to accept the solutions or modify them using provisional 
planning techniques. The AC will then request the AT to 
send the resolutions to the ST for display to the controller 
through a fully developed display interface. The con- 
troller will provide an input to the ST to notify the AC 
(through the AT display interface) whether the advisory is 
accepted or rejected. The ST will provide full automatic 
conflict detection in addition to the tools provided in 
Phase I. Automatic detection should allow the controller 
to devote more attention to other tasks required in this 
phase, such as acceptance or rejection of AT advisories. 
Extensive human factors development is expected during 
this phase. A limited operational deployment could 
possibly be achieved after Phase 2; if so, the deployment 
is expected to be limited to a set of sectors chosen on the 
basis of benefits and cost. 

Phases 1 and 2 will require the use of an auxiliary display 
and an additional controller to be located at each sector 
position. To maintain all current radar controller opera- 
tions, the additional controller will interact with the ST 
and then will transfer advisory clearances to the radar 
position (R-side). The display should provide a plan-view 
graphical interface and a keyboard for input. In addition 
to the proposed Phase 2 functions, this workstation should 
have all capabilities currently used to perform sector 
controller duties, such as accepting handoffs, displaying 
trend vectors, and providing tools for aiding separation 
maintenance. 

Sector-certified radar controllers will probably be 
required to interface with the auxiliary display. The 
handoff position could be responsible for monitoring the 
additional display for sectors with heavy traffic, and the 
interphone or flight-data (D-side) position could assume 
this responsibility for sectors with light traffic. When the 
ST is fully developed and approved for direct use by both 
the R- and D-side sector controllers, its functions will be 
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integrated into the sector controller display and the 
additional controller will no longer be needed. 

Research for Phase 2 will include evaluating the utility of 
AT cost-effective resolutions, evaluating various types of 
resolutions (e.g., single- or multiairerafl), developing 
automation algorithms for selecting the best resolution 
alternative, designing manual switching between AT 
resolution alternatives, and evaluating appropriate levels 
of advisories between AC/AT and the sector controller. 
The mature ST display interface will also be used to 
identify and resolve any remaining sector controller 
workload issues. ST filtering of AT conflict resolutions 
for display to the controller (display configuration logic) 
will be refined in Phase 2, based on the evaluations and 
preferences of sector controllers. Some of the 
development tasks arc as follows: 

• Develop an automated procedure for selecting an 
appropriate AT conflict resolution from a set of 
alternatives, based on awareness of the traffic 
situation at the sectors involved. For example, 
selection between two aircraft could be based on (he 
estimated workload (based on factors such as conflict 
density) of each owning controller. 

• Determine appropriate AT followup procedures tor 
rejection of conflict resolutions, based on awareness 
of the traffic situation at the sectors involved. For 
example, if a controller rejects an advisory, s(hc) may 
not want AT to attempt another resolution for that 
aircraft. 

• Determine whether duplicating the necessary AC 
awareness of a sector traffic situation in the AT 
automation system requires controller (AC and/or 
SC) inputs that have a negative impact on tool utility. 

• Determine, based on controller evaluations, whether 
the ST display information can be added to radar 
controller displays, or if it must continue to be 
displayed separately. 

• Determine the effectiveness of an auxiliary display, 
strip replacement, and/or integrated sector controller 
display/interfacc. 

Phase 3 

The full operating capability of the AT/ST concept w ill 
be attained in Phase 3. Development will focus on imple- 
mentation of functionality for deployment and for a 
research platform for advanced functionality. After 
Phase 3, the tools will be available for deployment over 
the entire Center airspace and in all sectors. An advanced 
display system (such as the DSR) will be used to display 
all AT/ST advisories directly to the sector controller. It is 


expected that most controllers will have incentive to use 
the tools, although some in light traffic areas may not 
require them. 

In Phase 3, the AT conflict resolution functions should be 
lully automated, so the AC will no longer be needed to 
direct the cost-effective conflict resolutions. The AC 
position will be freed to handle high-level planning tasks 
in addition to monitoring AT operation. The AC may be 
able to evaluate Center weather and traffic conditions and 
make recommendations to users for efficient routing. This 
scenario may require nonintrusive communication with 
the aircraft, such as datalink. The communication will 
also allow the AC to have real-time know ledge of user 
preferences that can be applied to manage the airspace. 
Future enhancements may also allow the AC to coordi- 
nate user preferences across Center boundaries or to 
facilitate dynamic rcsectorization based on actual traffic 
patterns. The fully operational tool will enable study of 
these advanced concepts, as well as the evaluation of new 
airspace management planning tools. Advanced ST 
research will concentrate on enhancing controller high- 
level planning under special conditions, such as enabling 
a transitioning aircraft to meet meter fix crossing restric- 
tions obtained from the CTAS Traffic Management 
Advisor (TMA) and using datalink to specify user pref- 
erence or negotiate a trajectory with an airborne FMS. 
These tasks may require high levels of intersector 
coordination, so ST automatic conflict resolution will also 
be studied for deployment in an advanced AT/ST system. 

Concluding Remarks 

An automated advisory system has been described that 
achieves many of the benefits of free flight w ithout 
radically modifying the procedures of ground-based air 
traffic control. Because it is based on the foundation 
provided by CTAS, significant operational capability 
can be achieved in the near future. It also provides a 
platform for exploring advanced concepts in air traffic 
management. 

The major features of the integrated AT/ST tools are as 
follows: 

• Many of the benefits anticipated for free flight are 
achieved with only small extensions to current ATC 
operations and procedures. All current sector con- 
troller responsibilities and authority arc preserved. 

All aircraft types can benefit because no new 
airborne equipment is required. 

• The needs of the entire Center airspace arc addressed. 
In en route environments, the integrated tool antici- 
pates and facilitates user preferences, while providing 
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advisory aids to help the controller solve complex 
traffic management problems. 

• An operational system can be placed in the field 
quickly, where it can serve as a testbed for new 
technology. Planned technology exploration includes 
trajectory negotiation with airborne flight manage- 
ment systems, integration with traffic schedulers 
such as TMA, and free-flight concepts that transfer 
responsibility for maintaining separation to the user. 

• Sector controllers will have an incentive to use the 
proposed system because it will improve their 
capability and reduce their workload. The system is 
not intended to be a replacement for controllers, but 
an aid to increase productivity. 

• The design leads to a logical and systematic 
evolution. It will be implemented as a series of 
new functions that will gradually increase system 
capability. Manual tasks will be automated based on 
the semi-automatic operation of early deployments, 
thereby freeing controllers to give attention to more 
advanced tasks as the design evolves. 

• The system is not dependent on planned hardware 
upgrades, such as DSR, to be successful. It will, 
however, take advantage of such upgrades. 

Although development of this system faces many 

challenges, no unresolvable implementation issues are 

anticipated. 
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